Vinay Prabhushankar, Murali Vadakke Puthanveetil presenting talk - Hidden Chains Revealing High-Impact Bugs from Bounty Submissions at Owasp Global Appsec Usa 2024
Vinay Prabhushankar, Murali Vadakke Puthanveetil presenting talk - Hidden Chains Revealing High-Impact Bugs from Bounty Submissions at Owasp Global Appsec Usa 2024

Effective bug bounty program management is a critical discipline for modern application security teams, transforming reactive bug hunting into a proactive source of high-impact security intelligence. This technical breakdown, based on a talk by Snapchat’s security leads Vinay and Murali, moves beyond theory to dissect three real-world, high-severity vulnerabilities discovered through their program. For experienced security engineers, these case studies offer a masterclass in advanced vulnerability analysis, revealing how hidden chains in dependencies and context-specific exploits can lead to critical risks.

We will explore a software supply chain attack involving a hijacked S3 bucket, an Android deep link vulnerability that forced video calls without user consent, and a clever escalation from blind XSS to remote code execution within a Jupyter notebook environment. You’ll not only understand the root causes of these complex bugs but also gain a strategic framework for maturing your own bug bounty program, using metrics, researcher engagement, and gamification to harden your applications at scale.

Key Takeaways

  • You'll learn to identify and mitigate transitive dependency risks in your software supply chain, as shown by a real-world FS Events S3 bucket takeover.
  • You'll be able to recognize how a seemingly low-impact vulnerability like a blind XSS can be chained to achieve high-impact RCE in specialized environments like Jupyter notebooks.
  • You'll gain actionable strategies for launching, maturing, and measuring the success of a bug bounty program, from setting up initial capabilities to using metrics for continuous improvement.

Uncovering Hidden Risks in the Software Supply Chain

Effective bug bounty program management requires a deep understanding of modern attack vectors, including those targeting the software supply chain security of your applications. This case study, referred to as “Stranger Events,” provides a stark example of how a transitive dependency within the Node.js ecosystem led to a widespread vulnerability, highlighting crucial gaps in conventional scanning and incident response processes.

The Anatomy of a Transitive Dependency Attack

The vulnerability originated in FS Events, a popular file monitoring library for Node.js with over 19 million weekly downloads. For most developers, FS Events was not a direct dependency but a transitive dependency: a dependency of a dependency. A common attack chain was:

  1. A developer uses a popular tool like nodemon for monitoring file changes.
  2. It depends on a library called chokidar.
  3. chokidar, in turn, depends on FS Events.

This indirect inclusion meant developers were often unaware that FS Events was even part of their project’s build.

The core vulnerability in older versions of FS Events was that its build process downloaded and executed a pre-built binary package from a hardcoded S3 bucket. This behavior alone is a significant security red flag for any package distributed via a public repository like npm. The attack was executed when the original developer deleted the S3 bucket, and, due to AWS behavior that releases a bucket’s namespace after a period of up to three months, a security researcher was able to claim the bucket name and begin serving a different binary.

Case Study: RCE via Transitive Dependency in the FS Events Package (Remote Code Execution via Hijacked S3 Bucket in a Transitive Dependency)

Proof of Concept Steps / Technical Write-up:

  1. Identify the Transitive Dependency Chain: The attack vector originates in the FS Events package, which is not a direct dependency but a transitive dependency. Developers use the popular nodemon utility, which depends on the chokidar library, which in turn depends on FS Events. This dependency chain meant FS Events was present on many Node.js developer machines.
  2. Discover the Insecure Build Process: The older version of the FS Events package was hardcoded to download a pre-built binary from an Amazon S3 bucket as part of its installation (npm install) process. This practice of downloading and executing an external binary from an uncontrolled source during a package build is inherently risky.
  3. Exploit the Abandoned Asset: The maintainer of FS Events had deleted the S3 bucket. Following AWS’s namespace release policy (which can take up to three months), the bucket name became available for public registration.
  4. Hijack the S3 Bucket: The security researcher identified this abandoned asset and successfully claimed the S3 bucket name, gaining full control over the content served from it.
  5. Deploy the Proof-of-Concept Payload: The researcher uploaded a custom binary to the hijacked bucket. This binary was not actively malicious but served as a PoC. Its function was to collect basic information from the execution environment, such as the present working directory and machine name, and send it back to the researcher to confirm successful code execution.
  6. Trigger Execution: A developer at the target company ran npm install for a project containing nodemon. The installation process transitively fetched the vulnerable FS Events package, which then downloaded and executed the researcher’s PoC binary from the hijacked S3 bucket, achieving Remote Code Execution (RCE) on the developer’s macOS machine.

This case study is a critical example of a software supply chain security failure. The vulnerability was not in the application code itself but in a third-party, transitive dependency (FS Events). A security researcher discovered that the package downloaded a binary from an S3 bucket that had been deleted by the original maintainer. By exploiting the delay in AWS’s bucket name release policy, the researcher was able to register the abandoned bucket name and replace the legitimate binary with a proof-of-concept payload.

When a developer ran a standard npm install, the build process automatically fetched and executed the researcher’s code, leading to RCE. The incident was particularly insidious because it was not associated with a CVE and therefore was not caught by standard open-source vulnerability scanners that rely on CVE databases. The payload was confirmed to be a non-malicious PoC that only affected macOS systems, but it demonstrated a severe breakdown in the software supply chain that could have been exploited with truly malicious code. The final remediation involved patching the dependency and working with AWS to place the S3 bucket name on a reserved list, preventing future takeovers.

Detection Gaps and Incident Response

A critical lesson from this incident was the failure of traditional security tooling. A GitHub advisory was created for this vulnerability, but crucially, it was not assigned a CVE identifier. Because most open-source vulnerability scanners rely primarily on public CVE databases, this high-risk issue went undetected by automated tooling.

When a bug bounty report confirmed command execution in their environment, the Snapchat security team initiated a full incident response, which included:

  • Payload Analysis: The detection and response team analyzed the binary and confirmed it was a proof-of-concept affecting only macOS, designed to collect basic environment information like the working directory and machine name. While not “intentionally malicious,” the potential for Remote Code Execution (RCE) was clear.
  • Comprehensive Scanning: The team performed a full scan of all services to identify every instance of the vulnerable FS Events package.
  • Endpoint Detection: They leveraged endpoint detection software to scan all developer laptops for vulnerable versions.
  • Systemic Remediation: After patching internally, the team worked directly with AWS to have the fs-events bucket name added to a reserved list, preventing any future takeovers and fixing the root cause for the entire community.

This incident underscores the importance of a mature incident response capability, heavily reliant on an accurate service inventory to quickly identify and contact service owners for patching.

Tools Involved

  • nodemon: A popular Node.js developer tool that included chokidar as a dependency, which in turn made FS Events a transitive dependency in many projects.
  • chokidar: A file-watching library that served as the intermediary dependency connecting nodemon to the vulnerable FS Events package.

Actionable Takeaways

  • Maintain a robust and actively updated service inventory. The transcript emphasizes that an abandoned inventory with outdated ownership information severely hinders Mean Time to Respond (MTTR) during an incident, as you cannot quickly route findings to the correct engineering teams for patching.
  • Enhance dependency scanning capabilities beyond CVE-based databases. Since this vulnerability was disclosed in a GitHub advisory without a CVE, it highlights the need for scanners that can ingest intelligence from multiple sources to detect modern software supply chain risks.
  • When a supply chain vulnerability is identified, work with external partners like cloud providers or package maintainers to pursue systemic fixes. In this case, getting AWS to reserve the hijacked S3 bucket name prevented future exploitation across the entire ecosystem, not just within one company.

Common Pitfalls

  • Relying solely on scanners that use CVEs as their only source of vulnerability data. This creates a critical blind spot, as many significant vulnerabilities, especially in the open-source supply chain, may be disclosed through other channels like GitHub Advisories first.
  • Neglecting the maintenance of your service inventory. An outdated inventory with incorrect service owners is a common failure point that turns a straightforward patching process into a prolonged incident response scramble.

Context-Driven Vulnerability Escalation in Mobile and Data Environments

Understanding how application context magnifies vulnerability impact is a cornerstone of advanced bug bounty program management. As demonstrated by two distinct application security case studies from Snapchat’s program, a vulnerability’s severity is not absolute; it is defined by the environment in which it executes and the features it interacts with. This section dissects an Android deep link vulnerability and a critical Jupyter Notebook security flaw to illustrate this principle.

This case study began with a report showing that clicking a specific web link could force the Snapchat Android app to initiate a video call without any user confirmation, a significant privacy violation. The exploit relied on a chain of conditions and the interaction between Snapchat’s mobile and web clients.

Proof of Concept Steps / Technical Write-up:

  1. Prerequisite: The attacker must first establish a “friend” connection with the victim on the Snapchat platform. This attack cannot be performed on arbitrary, non-friend users.
  2. Information Gathering: The attacker initiates a conversation with the victim using the Snapchat web client. This step is critical for capturing the unique conversation_id associated with their chat session. This ID is not typically exposed on the mobile application but was available through the web interface.
  3. Payload Crafting: The attacker constructs a malicious URL using the Snapchat application’s custom URI protocol. The specially crafted deep link follows this structure: snapchat://chat/new?calling_media_type=video&conversation_id=[CAPTURED_ID]&is_group=false
    • snapchat://: The protocol that tells the Android OS to open this link with the Snapchat app.
    • chat/new: The action to be taken by the app.
    • calling_media_type=video: Specifies that a video call should be initiated.
    • conversation_id=[CAPTURED_ID]: The unique identifier for the chat between the attacker and victim, obtained in the previous step.
    • is_group=false: Defines the call as a one-to-one interaction.
  4. Delivery and Social Engineering: The attacker sends the crafted deep link to the victim through an out-of-band channel, such as an email or a message on a separate platform.
  5. Exploitation: The victim clicks the link. The Android operating system routes the request to the installed Snapchat application as an intent.
  6. Outcome: The Snapchat application processes the deep link and its parameters. Due to the vulnerability, the app automatically executes the command and initiates a full video call from the attacker to the victim. The key flaw is that this action occurs without any user confirmation dialogue (e.g., an “Accept Call” prompt), directly violating the user’s privacy and intent.

This application security case study demonstrates a critical Android deep link vulnerability that allowed an attacker to force a victim into a video call without their consent. The root cause was the application’s improper handling of intents passed via a custom URI scheme (snapchat://). The application implicitly trusted the parameters within the deep link and failed to require user confirmation before executing a sensitive action—initiating a video call.

The attacker creatively chained two different platform features: the Snapchat web client, to obtain a necessary conversation_id, and the mobile application’s vulnerable deep link handler. By crafting a specific URL and tricking the user into clicking it, the attacker could trigger the call. This is a powerful example of how features that are secure in isolation (web chat, mobile deep links) can be combined to create an exploit. The bug was reported through the bug bounty program, and its investigation led to the establishment of a “privacy bug bar,” highlighting the need to evaluate bugs not just for security impact but also for privacy violations. The fix involved adding a user confirmation dialog before initiating a call from a deep link, ensuring user intent is explicitly captured.

Case Study 2: Escalating Blind XSS to RCE in Jupyter Notebooks

This incident demonstrates a powerful escalation from a seemingly low-impact vulnerability to full remote code execution, highlighting the unique risks associated with Jupyter Notebook security. The report started as a classic blind Cross-Site Scripting (XSS) finding, but internal investigation uncovered a critical data flow and execution context that turned it into an RCE.

Proof of Concept Steps / Technical Write-up:

  1. Initial Injection: The attacker injects a specially crafted XSS polyglot payload into a field that is likely to be logged, such as the User-Agent string of their HTTP requests. This is a form of Blind XSS, as the execution is not immediate.
  2. Log Aggregation: The application backend processes the request and stores the full request details, including the malicious User-Agent, into a log aggregation and data warehousing system like BigQuery. The payload remains dormant in the database.
  3. Data Analysis Trigger: A data scientist, using a Jupyter Notebook for internal analysis, queries the BigQuery database to pull logs for a report. This action retrieves the attacker’s stored payload.
  4. Unsafe Rendering: The Jupyter Notebook environment renders the output from the data query. Crucially, as per the Jupyter security model described, output generated from a user-initiated execution is considered trusted. Therefore, the notebook renders the malicious string from the logs without sanitization, triggering the XSS in the data scientist’s browser.
  5. Context Escalation: The executed JavaScript payload is not a simple alert(). It is crafted to interact with the underlying IPython kernel, which manages the code execution for the notebook from the backend. The JavaScript can issue commands directly to this kernel.
  6. Code Execution Command: The JavaScript payload sends a command to the IPython kernel, instructing it to execute arbitrary system commands. For example, a payload can be crafted to call IPython.notebook.kernel.execute('!open /System/Applications/Calculator.app') (on macOS) or a similar command for other operating systems.
  7. Remote Code Execution (RCE): The IPython kernel—which is running on the data scientist’s client machine—receives and executes the command. This breaks out of the browser sandbox and achieves Remote Code Execution on the victim’s machine, with the privileges of the user running the notebook.

This is a classic example of chaining a low-severity Blind XSS to a critical-severity RCE by exploiting the specific context of the execution environment. The attack began when a researcher injected an XSS payload into the User-Agent string, which was subsequently stored in a BigQuery database. The vulnerability lay dormant until a data scientist queried this data within a Jupyter Notebook.

The core of the escalation hinged on a critical aspect of Jupyter Notebook security: its security model considers output from user-initiated code execution to be trusted. When the notebook rendered the log data, the malicious script executed. This script was designed to communicate with the notebook’s backend IPython kernel, effectively creating a bridge from the browser’s JavaScript environment to the Python execution environment running on the data scientist’s local machine. This allowed the attacker to execute arbitrary system commands, turning a simple Blind XSS into a full RCE. This case study powerfully illustrates how the impact of a vulnerability is dictated by its environment and why security teams must analyze how data flows between different internal systems, especially powerful developer and data science tools.

Actionable Takeaways

  • Analyze feature interactions during security reviews: When introducing a major new feature (like a web client for a mobile-first app), thoroughly assess how it interacts with existing functionalities (like deep links) to identify and mitigate unintended behaviors.
  • Re-evaluate vulnerability severity based on context: Do not blindly accept a researcher's initial severity rating. A seemingly minor flaw like a blind XSS can become critical in specialized environments like Jupyter Notebooks, where it can be chained to achieve RCE.
  • Prioritize patching and securing data science environments: Regularly audit and patch Jupyter Notebook versions across your organization. Whenever possible, encourage the use of centrally managed, cloud-hosted Jupyter environments to offload patching and better control the execution environment.

Common Pitfalls

  • Underestimating the impact of XSS in specialized environments: Assuming an XSS vulnerability is limited to browser-based actions (like cookie theft) without considering if the application context (e.g., Jupyter, Electron apps) provides a bridge to a more privileged execution environment like a local kernel or file system.
  • Failing to re-evaluate security models when new features are added: The Android vulnerability arose because a new web feature exposed an identifier (`conversationId`) that was then used to exploit an older, insecure mobile feature (unconfirmed deep link action).

Establishing a Privacy-Aware Incident Response Framework

Effective bug bounty program management requires frameworks that extend beyond traditional security concerns. As demonstrated by a critical Android deep link vulnerability, some of the most impactful bugs violate user privacy without necessarily compromising system integrity. In that case study, a researcher discovered that a specially crafted deep link could force a user’s device to initiate a video call without their explicit consent. This event prompted the security team to classify the issue as a “privacy incident,” highlighting the need for a dedicated response framework for such cases.

The core of this framework is the establishment of a privacy bug bar, a set of criteria used to evaluate and prioritize bugs based on their impact on user privacy, which runs in parallel to a standard security bug bar.

Key Factors for a Privacy Bug Bar

Determining the severity of a privacy-related bug involves a nuanced evaluation beyond typical CVE scoring. The following factors were identified as crucial for building a robust privacy bug bar:

  • Data Sensitivity: The severity should be weighted differently based on the type of data exposed or acted upon. The transcript differentiates between user-generated content, aggregated user content, and user metadata, each carrying a different sensitivity level.
  • Exposure Scale: The potential number of affected users is a critical multiplier. A flaw affecting only 0.1% of users in an A/B test is less severe than one impacting 50% of the user base.
  • Existence of a Friend Graph: The context of the relationship between the attacker and victim matters. An attack that can only be executed against a user’s “friends” is considered lower severity than one that can target any user. This is due to the implicit trust involved and the inability to randomly target strangers.
  • Likelihood of Exploitation: Similar to a security bug bar, this factor considers how easily an attacker can exploit the vulnerability in a real-world scenario.

By defining these factors in collaboration with legal and privacy teams, an organization can more effectively prioritize and respond to incidents that blur the line between a security flaw and a privacy violation.

Actionable Takeaways

  • Develop a formal "Privacy Bug Bar" in collaboration with legal and privacy teams. This framework should define severity based on factors like data sensitivity, exposure scale, and violation of trust boundaries (e.g., friend relationships) to enable better prioritization of privacy-centric vulnerabilities.
  • When introducing major new features (e.g., a web client for a mobile-first app), conduct thorough security reviews to analyze how they interact with existing functionalities. A new attack surface can expose previously protected elements, like the conversation ID in the case study, creating unintended exploitation paths.
  • For critical vulnerabilities in applications where patch adoption is not immediate (like mobile apps), implement post-fix telemetry and monitoring. Look for anomalous usage patterns, such as the unusual deep link URI source in the case study, to detect ongoing exploitation attempts against unpatched clients.

Common Pitfalls

  • Relying solely on a traditional security bug bar, which can lead to the under-prioritization of issues that primarily violate user privacy rather than compromising system integrity or data confidentiality.
  • Launching new features without re-evaluating their security impact on existing, seemingly unrelated functionalities, which can introduce new attack vectors as feature interactions change.

Maturing Your Bug Bounty Program: From Metrics to Gamification

Effective bug bounty program management requires moving beyond a “set it and forget it” mentality. For organizations with an established program, the key to sustained value lies in a continuous cycle of improvement fueled by data-driven insights, robust operational capabilities, and strategic researcher engagement. This involves treating the program not as a passive vulnerability intake funnel, but as an active, evolving security control that needs regular tuning and investment.

Foundational Capabilities for Scaling Your Program

Before you can effectively level up, certain operational pillars must be in place. These capabilities ensure you can handle the volume and complexity of findings from a mature program:

  • Risk-Based SLAs: Establish clear, risk-based Service Level Agreements (SLAs) for all vulnerabilities. This is critical for prioritization and ensuring engineering teams understand the timeframes for fixes.
  • Service Inventory: Maintain a robust and up-to-date service inventory that maps services to their owners. This is the single most important capability for reducing response times, as you can quickly route findings to the correct team. An abandoned inventory is a major roadblock during an incident.
  • Reachability & Completeness Analysis: Go beyond the single instance reported by a researcher.
    • Reachability: Prioritize fixing vulnerabilities on internet-exposed or end-user-facing services before internal ones.
    • Completeness: Perform variant analysis across your entire codebase to find and fix all instances of a reported vulnerability, not just the one provided in the proof-of-concept.
  • Cross-Functional Collaboration: A mature program requires seamless interaction with other teams, including developers, legal, privacy, and incident response, to handle complex issues that blur the lines between security and privacy.

Using Metrics to Drive Improvement

Once a program has been running for six months to a year, you have enough data to derive strategic insights. Regularly analyzing these metrics is crucial for identifying trends and justifying future investments.

  • Submissions by Asset: Track which domains, products, or services receive the most reports. This reveals what researchers are targeting. If critical assets are being ignored, you can use incentives to redirect their attention.
  • Submissions by Vulnerability Type: This is a crucial metric that should directly inform your security investments. A high volume of XSS or IDOR submissions, for example, signals a systemic weakness that needs to be addressed with a new framework or developer training.
  • Response Efficiency (MTTR): Monitor your Mean Time to Remediate (MTTR), from initial submission to closure. Also, track time to bounty, as this is a key factor for researcher satisfaction. A long payout cycle disincentivizes them from returning to your program.
  • False Positives & Out-of-Scope: A high rate of these submissions indicates that your program policy or scope definition is unclear. Refining your policy can reduce triage fatigue for your team.
  • Rewards by Asset & Severity: Analyzing your payout data helps with budgeting and forecasting. It highlights where your security spend is concentrated and can help justify investments in areas that are proving to be consistently vulnerable.

Gamification: Keeping Researchers Engaged

To prevent stagnation, you must actively engage the security researcher community. Gamification and targeted incentives can revitalize a program and focus attention where it’s needed most.

  • Provide a Positive Experience: The researcher experience is paramount. Offer candid feedback on payout decisions, treat researchers with respect (“the human behind the hacker”), and reduce friction by providing clear documentation or premium subscriptions for testing.
  • Time-Restrained Challenges: Create urgency and focus by offering bonus payouts for a limited time (e.g., two weeks) on a specific asset that has not received enough attention.
  • Live Hacking Events: Bringing researchers together can foster collaboration where they chain multiple low-severity findings into a single critical vulnerability.
  • Recognize and Reward: Simple acts of recognition go a long way. Publish a “bug of the month,” maintain a public leaderboard, offer small swag, and provide small monetary bonuses ($100) for exceptionally well-written reports. These incentives make researchers feel valued.

Tools and Resources for Program Management

  • securitytemplates: A recommended resource providing templates for bug bounty policies and safe harbor statements, useful for launching or refining a program.
  • HackerOne: The bug bounty platform mentioned as being used by the speakers to manage their program and through which findings were disclosed.

Actionable Takeaways

  • Implement a quarterly or semi-annual metrics review to analyze submissions by asset and vulnerability type. Use this data to justify strategic investments in secure-by-default frameworks, developer training, or targeted security campaigns.
  • Develop and launch a gamification initiative to re-engage researchers and direct their focus. Start small with a "bug of the month" program or a time-restrained bonus bounty on an under-tested application.
  • Establish and actively maintain a comprehensive service inventory that maps all applications and services to their current owners. This is the most effective way to reduce MTTR by ensuring vulnerabilities are routed to the responsible team immediately.

Common Pitfalls

  • Treating the bug bounty program as a "pentest as a service." The transcript calls this a "disaster," as it leads to a high volume of low-hanging fruit and overwhelms teams not prepared to handle it.
  • Letting the program stagnate. A "set it and forget it" approach leads to diminished researcher interest and missed opportunities. The program must be actively managed with new challenges, scope updates, and engagement efforts.

Frequently Asked Questions (FAQ)

What is a transitive dependency risk?

A transitive dependency is a dependency of your direct dependency. The risk arises because your project can inherit vulnerabilities from these indirect packages without your team explicitly adding them. As shown with the FS Events case, a vulnerability in a third-level dependency can lead to RCE in your environment, making comprehensive dependency scanning (beyond direct dependencies) critical.

Why is an XSS in a Jupyter Notebook so dangerous?

Unlike a typical web page, a Jupyter Notebook is an interactive development environment. Its web front-end communicates with a backend execution kernel (like IPython). An XSS vulnerability in this context can allow an attacker’s JavaScript to send commands to this kernel, breaking out of the browser sandbox and achieving remote code execution on the host machine running the notebook.

How does a “privacy bug bar” differ from a security bug bar?

A security bug bar typically prioritizes vulnerabilities based on their impact on system confidentiality, integrity, and availability (CIA). A privacy bug bar focuses on the impact to user privacy, using factors like data sensitivity, the scale of exposure, and the violation of user trust or intent. It helps properly classify and prioritize issues, like the forced video call, that may not compromise the system but still represent a severe flaw.

What is the first step to launching a bug bounty program?

The recommended first step is to launch a private program. This allows you to start small, control the volume of submissions, and build the necessary internal capabilities for triage, remediation, and payment before opening the program to the public. Starting with a clear scope, budget, and policy (using resources like securitytemplates) is essential.

Why is a constantly updated service inventory so important for incident response?

During a security incident, the goal is to remediate the vulnerability as quickly as possible (reduce MTTR). An accurate service inventory that maps every service to its technical owner allows the security team to immediately route the finding to the correct engineers for patching. Without it, valuable time is lost trying to identify who is responsible for the affected code.

Conclusion

The insights from Snapchat’s bug bounty program underscore three critical truths for modern application security: context is king, the supply chain is a primary battleground, and a bug bounty program is a dynamic security control, not a static service. The leap from a blind XSS to RCE in a Jupyter Notebook and the weaponization of an Android deep link a-world away from the web client that enabled it, are powerful reminders that vulnerability impact can only be understood through holistic analysis.

By building robust internal capabilities like an accurate service inventory, developing a privacy-conscious response framework, and actively managing researcher engagement through metrics and gamification, security teams can transform their bug bounty program from a simple bug-finding tool into a strategic engine for continuous improvement.

Tools & Other References:

Explore Domains

Application security Bug bounty Vulnerability management Software supply chain security

Learn Topics

Dependency management Jupyter notebook Xss Rce Android security Deep links Incident response Node.js Vulnerability analysis

Credits

▶️ Watch Original Talk - Hidden Chains: Revealing High-Impact Bugs from Bounty Submissions - Vinay Prabhushankar, Murali Vadakke Puthanveetil,