Skip to main content

​
At a glance

Before you start testing, read §5. Kernel sells browsers running in microVMs where you have root by design. That makes the line between what is in scope and what is not unusual for our product, and §5 is where we draw it precisely. Most invalid reports we receive are reports of intended behavior.

​
1. Our commitments

Kernel runs cloud browser infrastructure. Our customers trust us to keep their sessions, credentials, and data isolated from every other tenant, so we take that boundary seriously and we want to hear from you when it does not hold. When working with us under this policy, you can expect us to:
  • Respond to your report promptly, and work with you to understand and validate it
  • Keep you informed about the progress of a vulnerability as it is processed
  • Work to remediate discovered vulnerabilities in a timely manner, within our operational constraints
  • Recognize your contribution if you are the first to report a unique vulnerability and your report triggers a code or configuration change
  • Extend safe harbor for vulnerability research related to this policy
You will receive a response confirming receipt of your report, written by a person rather than generated automatically, plus timely updates through remediation. You may request an update at any time. If we are going to miss one of the targets in §9 we will tell you before we miss it and give you a new date.

​
2. How to report

Submit through our HackerOne program. Keep all report information on HackerOne. Please do not post it to video sharing or paste sites. Every report must include the boundary statement described in §5. Reports without it are much slower to triage and are likely to be closed as intended behavior.

​
3. Rewards

Fixed values by severity. No ranges and no negotiation, so you can predict what you will be paid before you submit. Discretionary bonuses. For an exceptional report, whether a novel technique, a chained exploit, or an unusually good writeup, we may pay up to 2x the band. This is discretionary and not something you should expect, but it exists and we use it. We know this table sits below the market rate for infrastructure companies. We would rather publish a number we can honor on a 14 day clock than advertise one we cannot. Raising the table is the first item on the agenda at our six month program review. We will not reduce this table. If a report is submitted while a given table is published, it is paid at that table. If we ever need to stop paying, we will pause new submissions rather than quietly reprice.

​
4. Scope

​
Tier 1: primary targets

Reports against Tier 1 assets receive the highest bounty consideration and are reviewed first.

​
Tier 2: in scope, lower priority

If a Tier 2 report demonstrates critical or high severity with a clear, reproducible exploit chain and real world impact, we will consider awarding at Tier 1 levels case by case. We review and update this scope at least every six months, and we date every change. If you report something on an asset we had not listed and it turns out to be ours, we will add it to this page rather than closing you out on a technicality. If you are not sure an asset is ours, ask on the program before you test it. Our egress IP space is mostly customer browser traffic, so guessing wrong here means testing someone else’s system rather than ours.

​
High impact findings

We are particularly interested in findings that enable compromise of other customers’ sessions or data, or that reach Kernel’s core infrastructure. These behaviors are not limited to specific vulnerability categories, but examples include:
  • Breaking out of a browser session microVM to the host or hypervisor
  • Reading or influencing another tenant’s session, profile, credentials, cookies, or replays
  • Forging, replaying, or escalating the scope of a session token
  • Remote code execution on Kernel control plane or metro infrastructure
  • Exposure of Kernel infrastructure secrets such as signing keys, shared tokens, or cloud credentials
  • Cross VM attacks that break the single tenancy guarantee
  • Authentication or authorization bypass on the control plane or data plane

​
Out of scope: customer resources

Kernel runs browsers on behalf of customers, and we own a large amount of infrastructure that is serving customer workloads rather than running our own code. These are out of scope and must never be tested:
  • Any browser session, profile, deployed app, or data belonging to another Kernel customer
  • Code that a customer runs inside their own session, and websites their agents visit
  • Attribution based solely on an IP address in our ranges. Our egress IPs are customer browser traffic. Scanner output attributing a third party site’s issues to Kernel because the traffic left our network is out of scope.
Repeated submissions targeting other Kernel customers may result in removal from the program.

​
Out of scope: assets

  • adminkernel.sh and botcheck.kernel.sh, which are internal and gated behind access controls
  • xds.onkernel.com, the operator control plane
  • trust.kernel.sh and status.kernel.sh, which are hosted by third parties
  • Third party services. Report these to the vendor, not to us: Clerk, Vercel, Cloudflare, AWS, PlanetScale, Stripe, Metronome, Temporal Cloud, SigNoz, PostHog, incident.io, Resend, Unikraft Cloud / UKC, CapMonster, OpenRouter, Bright Data, Ping Proxy, Stainless.

​
5. What is not a vulnerability: the boundary

Read this section before you start. Kernel’s product is a browser running in a single tenant Unikraft microVM that you control. Root access, SSH, process.exec, and fs.readFile inside your own session are intentional features, and they are documented as such in our public security documentation, §2.4:
“features like SSH access and full shell control are safe by design: users operate within their own ephemeral VM, and any modifications are contained to that session with no impact on other customers or platform infrastructure”
“I can run code on the browser VM” is the most common invalid report we receive, and it is a product feature rather than a finding. So is having root, installing software, reading the filesystem, killing processes, and reconfiguring Chromium. Our security model is about preventing you from getting out of your own box, not about restricting what you do inside it. Issues that remain contained to a single session are generally not security issues at all. The claim worth attacking is the second half of that quote, not the first. If you can show that something you do inside your own session is not contained to it, meaning it reaches another customer, the host, the hypervisor, or Kernel’s infrastructure, that is a finding, and at Critical it is the highest reward we pay. Accordingly, the following are excluded unless they demonstrate impact beyond the boundary of your own session:
  • Privilege escalation, root access, or capability use inside your own VM. Kernel sessions provide root by design. Findings that chain to host or hypervisor escape, or to access of another tenant’s session, remain in scope and are treated as Critical.
  • Findings within your own session that do not demonstrate impact beyond that session’s isolation boundary.
  • Denial of service against your own VM. Exhausting the resources of a session you own affects only that session.
  • Reading or modifying data you supplied to your own session, meaning your own credentials, cookies, profile data, and files.
  • Reading your own session’s ephemeral proxy credentials and routing configuration. These are issued per session, are valid only for that session’s lifetime, and cannot be reused against other sessions.
  • Command injection into values that only Kernel’s provisioning infrastructure sets, for example PROXY_HOST, PROXY_PORT, PROXY_USERNAME, PROXY_PASSWORD, and KERNEL_IMAGES_API_VIDEO_ENCODER. If you can demonstrate an external path to influence these values, that path is in scope and we want to see it.
Configuration you already control is not an attack surface. A finding qualifies only where the attacker does not initially control the configuration of the session under attack. Weakening the posture of a session you own, whether by disabling protections, exposing resources, or altering the runtime configuration, and then demonstrating impact within that same session, is intended behavior. Being able to affect the configuration of a session you do not own is in scope and is Critical. Code you execute, pages you browse, and content you load inside your own session are controlled by you and are not part of Kernel’s product surface.

​
State the boundary you crossed

Every report must state:
  1. Starting privilege: unauthenticated, API key holder, code execution as an unprivileged user in your own VM, root in your own VM, or holder of a leaked credential
  2. Boundary crossed: none, VM to host, session to session, tenant to tenant, control plane, or infrastructure secret
  3. What an attacker concretely reads, writes, or executes on the other side of that boundary
Reports that do not identify a crossed boundary will be closed as intended behavior. This is not a formality. It is the fastest way for both of us to establish whether there is a finding here.

​
6. Ineligible findings

HackerOne’s Core Ineligible Findings apply in full. In summary, we close the following as invalid, except where you demonstrate clear security impact: Theoretical issues requiring unlikely interaction or circumstances. Browsers and operating systems that are unsupported or no longer receive updates; broken link hijacking; tabnabbing; content spoofing and text injection; attacks requiring physical device access; self exploitation, for example cross site scripting or denial of service that affects only your own account, unless it can be used to attack a different account. Issues without demonstrated real world impact. Clickjacking on pages with no sensitive actions; CSRF on forms with no sensitive actions; permissive CORS without demonstrated impact; software version disclosure; banner identification; descriptive errors or stack traces; CSV injection; open redirects without additional impact. Optional hardening and missing best practices. TLS configuration opinions; cookie flags such as HttpOnly and Secure; Content Security Policy opinions; optional email security features such as SPF, DKIM, and DMARC; most issues related to rate limiting. Also ineligible:
  • Intended platform behavior, including root in your own VM, outbound network access from your session, proxy routing, CAPTCHA handling, browser fingerprint configuration, rate limiting, quota enforcement, and usage caps behaving as designed
  • Use of the CapMonster or hCaptcha relay with your own live, billed session. The relay hides our API key; it does not gate use, and cost is bounded by the session you are paying for. Using the relay without a valid active session, or against another org’s session, is in scope and treated as High.
  • Known vulnerable dependencies or outdated Chromium versions without a working exploit against Kernel
  • Newly published CVEs, zero days, and n days are subject to a 30 day cooling period from public patch release. They are reportable during that window but not bounty eligible. After 30 days, if the issue is still live in our environment, it becomes eligible at the §3 table.
  • Publicly known processor side channel attacks. There is no safe way to test these against shared production hardware. If you have strong reason to believe such an issue affects our environment, email security@kernel.sh and we will work with you to set up an environment for safe testing.
  • Reports generated by automated tools or AI assistants without manual validation. Scanner output, hallucinated or unverified claims, and reports without a working exploit will be closed as Not Applicable, will not hold a place in the duplicate queue, and a pattern of such submissions will get you deprioritized or removed from the program.

​
7. Rules of engagement

​
Getting set up to test

  • Create your own account at dashboard.onkernel.com. Register it with your HackerOne @wearehackerone.com alias and use dedicated test accounts only. If you test with an account not tied to that alias, we may lock or ban it as suspected malicious activity. Adding the alias does not exempt you from our Terms of Service or from this policy.
  • Ask for test credits before you start, not after. Kernel is metered and browser sessions bill by the hour, so a long investigation can cost you real money. Ask on the program and we will grant complimentary credits for research. Credits are for research under this policy only and may be revoked.
  • Where a surface needs credentials we have to issue, such as a managed auth connection, ask on the program and we will provision them rather than have you test against anything of a customer’s.
  • Everything in §4 is reachable from a normal account. Nothing in this program requires you to be a paying customer.

​
Traffic identification and limits

  • Send X-HackerOne-Research: <your-username> on all HTTP traffic to Kernel APIs. Most proxies can add this automatically. This is how we distinguish research from abuse, and it substantially reduces the chance you get blocked. We also accept X-Bug-Bounty: HackerOne-<your-username> if your tooling already sets that.
  • Limit automated tooling to 10 requests per second against Kernel APIs and the metro data plane. Automation inside your own session VM is unrestricted.
  • Terminate your sessions when you finish testing. Kernel is metered. We do not reimburse compute charges incurred during research beyond credits we have explicitly granted. If we grant you complimentary access for testing, it is solely for that purpose and may be revoked at any time.
  • Only interact with accounts, sessions, and VMs you own.
  • Do not attempt to achieve or maintain persistence on any system owned by Kernel.

​
Proof of concept limits

Prove the primitive and stop. We will determine the full impact ourselves, and we will award for the maximum impact we uncover, so you lose nothing by stopping early. If the only way to demonstrate impact is disruptive, stop and report. We will validate the impact ourselves.

​
Data handling

Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. If a vulnerability gives you unintended access to data, limit what you access to the minimum needed for a proof of concept. If you encounter another tenant’s data or any personal information, stop immediately, do not enumerate further, do not retain copies, and report within 24 hours. Delete all local, stored, and cached copies as soon as possible. We may ask you to certify deletion; doing so will not affect your reward.

​
Availability

There are no limits on denial of service research against your own session VM, and this is the method we strongly prefer. Do not test denial of service against Kernel’s API, control plane, metro data plane, or shared infrastructure. We do allow automated tooling so long as it does not produce excessive traffic. One nmap scan against one host is fine. Sixty five thousand requests in two minutes from an intruder tool is not. Stop immediately if you believe you have affected the availability of our services. Do not worry about demonstrating the full impact; Kernel’s security team will determine it.

​
Do not use Kernel as an attack platform

This matters more for us than for most programs, because our product is a fleet of real browsers with real network egress. Authorization under this policy extends only to Kernel’s own in scope assets. It does not authorize you to point a Kernel browser session at any third party system. Specifically, do not use Kernel sessions to scan, fuzz, or exploit third party sites; conduct credential stuffing, brute forcing, or token harvesting; send spam or phishing content; generate request floods against any destination; or scrape in a way that degrades a third party’s service. A bug bounty authorization granted to you by another company does not extend to attacking that company from Kernel infrastructure. Permission you hold from a third party governs your relationship with that third party. It does not authorize abusive traffic originating from our network. If you are authorized to test a third party target, do it from infrastructure you control. Nothing in this policy waives our right to pursue remedies for activity targeting other Kernel customers’ sessions, data, or end users, or third parties reached through our network. Research not conducted in good faith may result in session termination, account suspension, forfeiture of bounty eligibility, and referral to law enforcement.

​
8. How we determine severity

Submit a CVSS v3.1 vector with your report. If a severity rating accompanies your disclosure, we will generally rely on it as a starting point, but may upgrade or downgrade the severity in our best judgement. Kernel is multitenant infrastructure, and we assess impact against our own trust boundaries rather than against a generic deployment. On receipt we investigate to understand full impact, accounting for existing mitigations, the sensitivity of data actually reachable, the number of customers affected, and whether the demonstrated access crosses a boundary we treat as security relevant. Sometimes an otherwise critical vulnerability has very low impact simply because it is mitigated by another component. Where we treat a component as untrusted by design, as we do with code running inside a customer’s own session, a finding that stays within that boundary may be rated below its generic CVSS score, or closed as informative. §5 sets out exactly where those boundaries are, in advance, so this is a published rule rather than a case by case judgment call. Where CVSS is not an appropriate instrument, for example a leaked document or credential with no demonstrated exploitation path, we award a discretionary bounty based on our assessment of impact. Every severity decision is reviewed by a second Kernel engineer before a bounty is paid, and we will explain the rationale for any change to your rating in a comment on the report, including the criteria we applied. If you believe we have misjudged a metric, raise it on the report and we will review it again. The final decision on severity and bounty amount rests with Kernel.

​
9. Response and remediation commitments

We make a best effort to meet the following, in business days. First response means a human being engaging with your report. We do not count an automated acknowledgement. If we are going to miss one of these, we will say so on the report before we miss it and give you a revised date. The only appropriate place to ask about a report’s status is on the report itself. Please do not inquire through unrelated reports or other channels, because it binds resources on a small team. Remediation. Vulnerabilities affecting Kernel’s systems will be remediated within a timeframe appropriate to severity, subject to the public availability of a patch or other remediation instructions: Where a fix must reach our browser VM fleet, the timeframe includes fleet rollout, not just merge.

​
10. Safe harbor

Kernel adheres to HackerOne’s Gold Standard Safe Harbor. Gold Standard Safe Harbor supports the protection of organizations and hackers engaged in Good Faith Security Research. “Good Faith Security Research” is accessing a computer solely for purposes of good-faith testing, investigation, and/or correction of a security flaw or vulnerability, where such activity is carried out in a manner designed to avoid any harm to individuals or the public, and where the information derived from the activity is used primarily to promote the security or safety of the class of devices, machines, or online services to which the accessed computer belongs or those who use such devices, machines, or online services. We consider Good Faith Security Research to be authorized activity that is protected from adversarial legal action by us. We waive any relevant restriction in our Terms of Service (“TOS”) and/or Acceptable Use Policies (“AUP”) that conflicts with the standard for Good Faith Security Research outlined here. This means that for Good Faith Security Research conducted with a good faith effort to comply with our program guidelines and while this program is active, we:
  • Will not bring legal action against you or report you, including for bypassing technological measures we use to protect the applications in scope; and,
  • Will take steps to make known that you conducted Good Faith Security Research if someone else brings legal action against you.
You should contact us for clarification before engaging in conduct that you think may be inconsistent with Good Faith Security Research or unaddressed by our guidelines. Keep in mind that we are not able to authorize security research on third-party infrastructure, and a third party is not bound by this safe harbor statement. Precedence and specific waiver. These terms supplement Kernel’s Master Services Agreement. Where any inconsistency exists between that agreement and this policy, this policy prevails with respect to your participation in this program. For the avoidance of doubt, we specifically waive MSA §3.4(b), the prohibition on disassembling, decompiling, reverse engineering, or otherwise attempting to discover the source code, underlying ideas, algorithms, or trade secrets of the Services, for the limited purpose of Good Faith Security Research conducted under this policy. Security research necessarily involves this activity, and we do not want that clause to create ambiguity about whether your testing is authorized. We reserve the sole right to determine whether a violation of this policy was accidental or in good faith, and proactive contact with us before acting is a significant factor in that determination. If in doubt, ask first. Cross tenant carve out. For the purposes of safe harbor, Kernel does not waive the right to pursue remedies against research activity targeting other Kernel customers’ sessions, resources, or end users, or third party systems reached through our network. See §7. Third party reports. If your report affects a third party service, we will limit what we share. We may share content that does not identify you with the affected third party, but only after telling you we intend to and obtaining their written commitment not to pursue legal action against you or contact law enforcement based on your report. We will not share identifying information about you without your written permission. If a third party initiates legal action against you and you have substantially complied with this policy, we will take steps to make known that your actions complied. Please be aware that while we treat reports as confidential, a court could order us to share information despite our objections. We cannot and do not authorize security research in the name of other entities, and this is not an agreement to defend, indemnify, or otherwise protect you from third party action.

​
11. Disclosure

We are rewarding you for finding a bug, not buying your silence. While this program is private, disclosure requires our written consent, and so does discussing the program itself. That is how private programs work on HackerOne, and their disclosure guidelines govern here. Please keep reports, resolved or not, inside the program until we agree otherwise. We commit to how we will use that consent, because a consent requirement is otherwise indistinguishable from a gag. Once a fix has been deployed to our fleet, ask and we will grant it. We will not withhold consent to keep a finding quiet, to avoid embarrassment, or because a writeup is unflattering, and we will not use it to renegotiate a bounty already paid. If we ask you to hold longer, we will tell you why and give you a date. If the program goes public, this requirement goes away and everything in the paragraph below applies unqualified. Subject to that, Kernel will not limit what you write. We ask that you refrain from publicly disclosing details until a fix has been deployed to our fleet, so that other Kernel customers are not exposed in the interim. The remediation targets in §9 tell you what “reasonable time” means in practice. We do not reserve the right to take forever. We may pay your reward before the fix ships, so payment is not contingent on delay. Where a finding affects both of us publicly, we prefer that our respective disclosures be posted simultaneously, and we are happy to credit you and link to your writeup. Vulnerabilities disclosed to a third party before being submitted to us are not eligible for a reward.

​
12. Reward eligibility and fine print

  • Please provide detailed reports with reproducible steps. If a report is not detailed enough to reproduce the issue, it will not be eligible for a reward.
  • Submit one vulnerability per report, unless you need to chain vulnerabilities to demonstrate impact.
  • When duplicates occur, we only award the first report received, provided it can be fully reproduced. Reports filed within 48 hours of each other for the same issue will split the reward.
  • Multiple vulnerabilities caused by one underlying issue will be awarded one bounty. For different attack vectors resolved by the same mitigation, we reward the first validated report, and all subsequent reports addressed by that mitigation are duplicates, regardless of attack vector. When we close your report as a duplicate we will share the relevant context from the original so you can see the call was fair.
  • Duplicate window. We will not hold an unresolved report open indefinitely as a shield against paying a later reporter. If we have not resolved a Critical within 90 days, a High within 180 days, or anything within 365 days, a subsequent report of the same issue becomes independently eligible for a bounty.
  • Bypasses are new reports. If you find a way around a fix we shipped for a previously reported issue, that is a new vulnerability and earns its own bounty at the §3 table, not a duplicate of the original.
  • Public disclosure of a vulnerability prior to resolution may cancel a pending reward.
  • We will not negotiate under duress. We will not negotiate a payout amount under threat of withholding a vulnerability, or of releasing it or any exposed data publicly.
  • We reserve the right to disqualify individuals from the program for disrespectful or disruptive behavior.
  • You are not eligible if you are currently a Kernel employee or contractor, were one within six months prior to submission, or collaborated on your submission with anyone who was. Reports from former employees, immediate family of current employees, or others where a conflict of interest may exist will be reviewed more thoroughly and may not qualify, at Kernel’s discretion.
  • We cannot reward any individual on any United States sanctions list, or residing in any country or region sanctioned by the United States. Reports from individuals we are prohibited by law from paying are ineligible for rewards.
  • You are solely responsible for any applicable taxes, withholding or otherwise, arising from your participation, including from any bounty payments.
  • You are responsible for complying with any policies your employer has that affect your eligibility to participate.
  • We may modify the terms of this program or terminate it at any time. We will not apply changes retroactively.
In order to encourage the adoption of bug bounty programs and promote uniform security practices across the industry, Kernel reserves no rights in this policy. You are free to copy and modify it for your own purposes. Questions: security@kernel.sh. Version: 1.0. Last updated: July 31, 2026 Owner: Kernel Security Engineering, security@kernel.sh Platform: HackerOne, program kernel_bbp, private and invite only