Bug Bounty

7 posts

github2 min readCurated summary

Next chapter: Restructuring GitHub’s bug bounty program

GitHub is restructuring its bug bounty program to prioritize high-quality, high-impact security research over report volume. The changes introduce a permanent VIP program with higher rewards and faster support, reduce and simplify public-program payouts, and add submission limits for researchers without an established track record. Reports submitted before July 27, 2026 will remain under the previous terms. ## Permanent VIP program for top researchers GitHub is creating a private, invite-only program for researchers who consistently produce valuable findings. - VIP researchers receive: - Higher payouts - Faster response times - Closer collaboration with GitHub’s security engineering team - VIP bounty payouts are: - Low: $1,000 - Medium: $7,500 - High: $20,000 - Critical: $30,000+ - Researchers can qualify by achieving at least one of the following: - One critical finding - Two high-severity findings - Four medium-severity findings - Seven low-severity findings - The program emphasizes quality and impact rather than the number of submissions. ## Restructured public bounty payouts GitHub is replacing variable payout ranges with fixed amounts to make rewards more predictable and reduce administrative overhead. - New public-program payouts: - Low: $250 - Medium: $2,000 - High: $5,000 - Critical: $10,000 - GitHub may still provide discretionary bonuses for exceptional work. - The public program will remain an entry point for new researchers and a pathway into the VIP program. ## Higher submission standards To address increasing report volume, including low-effort and AI-generated submissions, GitHub is adding a HackerOne signal requirement. - Researchers below the required signal threshold will have a limited number of submissions. - New researchers can make up to four initial submissions while establishing credibility. - The goal is to reduce noise without excluding legitimate newcomers. ## Existing commitments and transition period GitHub says it will continue paying quickly, communicating clearly, and treating researchers as security partners. - Reports submitted before the changes take effect will follow the old bounty structure. - Reports submitted on or after July 27, 2026 will use the new rules. - GitHub also plans to improve response times, severity explanations, and community engagement through conferences and outreach. The restructuring is designed to make GitHub’s bug bounty program more sustainable while directing greater rewards and attention toward researchers who deliver deep, thoughtful security work.

Read original(opens in new tab)
discord2 min readCurated summary

Every Voice and Video Call on Discord Is Now End-to-End Encrypted

Discord now uses end-to-end encryption by default for nearly every voice and video call, without requiring users to opt in. The rollout, completed in March 2026, relies on the open DAVE protocol and spans desktop, mobile, browsers, consoles, bots/apps, and the Social SDK. Discord says encryption was introduced without reducing call quality or performance, though Stage channels remain exempt. ## Building DAVE Across Platforms - Discord began experimenting with voice and video E2EE in 2023. - The DAVE protocol was introduced in 2024 as an open, audited encryption system. - Support was expanded to: - Desktop and mobile - Web browsers - PlayStation and Xbox - Discord bots and apps - The Social SDK - The protocol and its implementation are publicly available and open source. - Trail of Bits externally audited the design and implementation. - Discord expanded its bug bounty program to cover DAVE. - The team collaborated with Mozilla to fix a Firefox issue that interfered with encrypted calls. ## Reaching Default Encryption - Since early March 2026, E2EE covers calls in: - Direct messages - Group DMs - Voice channels - Go Live streams - All clients must support DAVE before joining a call. - Discord is removing unencrypted fallback code, after which calls will no longer be able to downgrade to unencrypted connections. - Encryption operates transparently, preserving expected call quality and latency. ## Why Stage Channels Are Excluded - Stage channels are intended for large-scale broadcasts, AMAs, live events, and town halls. - Their broadcast-oriented architecture differs from personal voice and video conversations. - Discord therefore continues to exclude them from E2EE. ## Future Privacy Work - Discord will continue maintaining and improving DAVE, including its open protocol and bug bounty program. - The company has no current plans to add E2EE to text messages. - Many Discord text features depend on server-side access to messages, so supporting encryption would require substantial redesign. Discord’s recommendation is effectively to treat DAVE as an ongoing privacy foundation rather than a finished project: voice and video calls are now protected by default, while the protocol remains open to inspection and continued improvement.

Read original(opens in new tab)
github3 min readCurated summary

Raising the bar: Quality, shared responsibility, and the future of GitHub’s bug bounty program

GitHub is reaffirming its commitment to external security researchers while tightening bug bounty submission standards. Rising report volumes—partly driven by AI and other tools—have increased both valuable findings and unvalidated noise. GitHub’s central message is that tools are welcome, but researchers remain responsible for validating vulnerabilities, demonstrating impact, and understanding the platform’s shared security boundaries. ## Rising Submission Volume - New tools, including AI, have lowered the barrier to security research and expanded the number of people examining attack surfaces. - GitHub has also seen more reports that: - Lack a working proof of concept - Describe only theoretical attack scenarios - Concern categories already listed as ineligible - Because this challenge affects the wider industry, some bug bounty programs have shut down; GitHub instead plans to improve its program. ## Requirements for Strong Reports - Submissions must include a working proof of concept demonstrating concrete security impact. - Researchers should show what an attacker can actually accomplish, rather than merely describing a possible attack path. - Reports must respect GitHub’s published scope and ineligible findings list. Examples of generally ineligible issues include: - DMARC, SPF, or DKIM configuration problems - User enumeration - Missing security headers without a demonstrated attack path - Scanner, static-analysis, or AI-generated findings must be manually validated before submission. - Unverified false positives create unnecessary triage work and may affect a researcher’s HackerOne Signal and reputation. ## AI Is Welcome, but Validation Is Required - GitHub supports the use of AI in security research and uses AI internally. - AI-assisted reports are acceptable when findings are reproduced, verified, and supported by a working proof of concept. - Researchers remain accountable for the accuracy of their submissions, regardless of which tools produced them. - GitHub recommends a concise report structure: - A short issue summary - Clear reproduction steps and evidence, such as screenshots, HTTP requests, or terminal output - An impact statement explaining what an attacker can achieve - Lengthy theoretical explanations and AI-generated filler can obscure the actual vulnerability and slow triage. ## Shared Responsibility and GitHub’s Security Boundary - GitHub protects users through automated scanning, manual review, and other systems for detecting malicious content. - Users are still responsible for deciding what repositories, issues, code, and scripts to trust. - Users should review content before executing or interacting with it. - Cloning a repository is considered an act of trust because Git hooks, build scripts, and other automation may run locally. - Users must also secure their own environments, including tokens, credentials, and local security settings. - Scenarios generally do not bypass GitHub’s security controls when they require victims to deliberately engage with attacker-controlled content. ## Common Shared-Responsibility Scenarios - Prompt injection in content a user intentionally provides to an AI tool - Git hooks or filters executing code from a repository the user checked out - Malicious content in a repository the user chose to clone - Unexpected LLM output caused by untrusted input supplied by the user Research into these areas remains useful when it identifies a way to bypass an actual GitHub security control without requiring the user to actively trust malicious content.

Read original(opens in new tab)
gitlab3 min readCurated summary

GitLab Patch Release: 18.11.1, 18.10.4, 18.9.6 | GitLab Docs

GitLab released patch versions 18.11.1, 18.10.4, and 18.9.6 on April 22, 2026, addressing multiple security vulnerabilities and bugs in CE and EE. Self-managed installations should upgrade immediately, while GitLab.com is already patched and GitLab Dedicated customers need no action. The fixes include unauthenticated GraphQL and browser-based attacks, several denial-of-service flaws, and access-control weaknesses. ## Release Scope and Upgrade Guidance - Applies to GitLab Community Edition and Enterprise Edition. - Affects all deployment types unless otherwise specified, including Omnibus, source installations, and Helm charts. - Recommended fixed versions: - 18.11.1 - 18.10.4 - 18.9.6 - GitLab issues detailing security vulnerabilities are made public 30 days after the relevant patch release. - GitLab publishes both scheduled patch releases, issued on the second and fourth Wednesdays, and ad-hoc critical patches for high-severity vulnerabilities. ## High-Severity Vulnerabilities - **CVE-2026-4922 — GraphQL CSRF** - CVSS 8.1. - An unauthenticated attacker could execute GraphQL mutations on behalf of an authenticated user because of insufficient CSRF protection. - Affects versions before 18.9.6, 18.10.4, and 18.11.1. - **CVE-2026-5816 — Web IDE path validation** - CVSS 8.0. - Under certain conditions, improper path validation could allow unauthenticated attackers to execute arbitrary JavaScript in a user’s browser session. - Affects the 18.10 and 18.11 release lines before the listed patches. - **CVE-2026-5262 — Storybook cross-site scripting** - CVSS 8.0. - Improper input validation could allow unauthenticated access to tokens in the Storybook development environment. - Affects versions from 16.1 through the unpatched 18.9, 18.10, and 18.11 releases. ## Denial-of-Service Fixes - **CVE-2025-0186:** Crafted requests to the discussions endpoint could exhaust server resources. - **CVE-2026-1660:** Improper input validation during Jira issue imports could enable resource exhaustion. - **CVE-2025-6016:** Insufficient limits when retrieving notes could cause service disruption. - **CVE-2025-3922:** Resource-allocation weaknesses in the GraphQL API could allow authenticated users to overwhelm the system. - Each issue carries a CVSS score of 6.5 and generally requires authentication. ## Access-Control and Session Fixes - **CVE-2026-6515 — Virtual registry credentials** - CVSS 5.4. - Invalidated or incorrectly scoped credentials could continue accessing Virtual Registries. - **CVE-2026-5377 — Confidential issue titles** - CVSS 4.3. - Authenticated users could potentially view titles of confidential or private issues in public projects. - **CVE-2026-3254 — Mermaid sandbox** - CVSS 3.5. - Improper validation could allow authenticated users to load unauthorized content into another user’s browser. - The release also lists **CVE-2025-9957**, involving improper access control in the project fork relationship API; the provided text does not include its full impact or severity details. Self-managed GitLab administrators should apply the appropriate patch release as soon as possible, especially because several vulnerabilities permit unauthenticated browser or API attacks.

Read original(opens in new tab)
gitlab2 min readCurated summary

GitLab Patch Release: 18.10.3, 18.9.5, 18.8.9 | GitLab Docs

GitLab released patch versions 18.10.3, 18.9.5, and 18.8.9 on April 8, 2026, addressing important security and bug fixes. Self-managed CE and EE installations should upgrade immediately, while GitLab.com is already patched and GitLab Dedicated customers need no action. The fixes cover unauthorized access, denial-of-service vulnerabilities, code injection, XSS, and information disclosure. ## Release Scope and Upgrade Guidance - The patches apply to GitLab Community Edition and Enterprise Edition. - Administrators should upgrade installations affected by the listed vulnerabilities to the latest supported patch release. - GitLab issues describing security vulnerabilities will become public 30 days after the release in which they were fixed. - Patch releases are generally issued on the second and fourth Wednesdays, with urgent ad-hoc releases for critical vulnerabilities. ## Authentication and Authorization Fixes - **CVE-2026-5173 (CVSS 8.5):** Authenticated users could invoke unintended server-side methods through WebSocket connections. - **CVE-2026-2619 (CVSS 4.3):** Auditor users could modify vulnerability flag data in private projects through the AI detection API. - **CVE-2026-1752 (CVSS 4.3):** Developers could modify protected environment settings through authorization flaws in the Environments API. - **CVE-2026-2104:** CSV exports could expose confidential issues assigned to other users because of insufficient authorization checks. ## Denial-of-Service Vulnerabilities - **CVE-2026-1092 (CVSS 7.5):** Unauthenticated attackers could crash or disrupt services through malformed JSON sent to the Terraform state lock API. - **CVE-2025-12664 (CVSS 7.5):** Repeated unauthenticated GraphQL queries could cause denial of service. - **CVE-2026-1403 (CVSS 6.5):** Authenticated users could disrupt Sidekiq workers by importing malformed CSV files. - **CVE-2026-1101 (CVSS 6.5):** Authenticated users could overload GitLab through improperly validated GraphQL SBOM queries. ## Code Execution and Cross-Site Scripting - **CVE-2026-1516 (CVSS 5.7):** Crafted Code Quality report content could leak the IP addresses of users viewing the report. - **CVE-2026-4332 (CVSS 5.4):** Authenticated users could execute arbitrary JavaScript in other users’ browsers through customizable analytics dashboards. ## Information Disclosure - **CVE-2025-9484 (CVSS 4.3):** Certain GraphQL queries could reveal other users’ email addresses to authenticated users. - The release also fixes CSV export authorization issues that could expose confidential issue data. Administrators of self-managed GitLab CE or EE instances should apply 18.10.3, 18.9.5, or 18.8.9 as soon as possible, depending on their supported release branch.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Fixing request smuggling vulnerabilities in Pingora OSS deployments

Pingora 0.8.0 fixes three HTTP/1.x request-smuggling vulnerabilities affecting standalone deployments used as Internet-facing ingress proxies. The flaws could let attackers bypass proxy security controls, desynchronize connections with backends, hijack other users’ sessions, or poison shared caches. Cloudflare’s own CDN was not affected, but Pingora users are urged to upgrade immediately. ## Scope and Impact - Vulnerabilities: - CVE-2026-2833 - CVE-2026-2835 - CVE-2026-2836 - Reported through Cloudflare’s bug bounty program in December 2025. - Affected deployments are standalone Pingora proxies exposed directly to the Internet. - Potential consequences included: - Bypassing ACL and WAF checks at the proxy layer. - Desynchronizing Pingora and backend HTTP connections. - Cross-user session or credential theft. - Cache poisoning when shared backends are used. - Cloudflare’s CDN was not vulnerable because Pingora is not used as its ingress proxy, and internal clients did not send pipelineable HTTP/1 requests to affected services. ## Premature Upgrade Without a `101` Response - Pingora treated a request containing an `Upgrade` header as an upgraded, pass-through connection immediately. - Under RFC 9110, the connection should switch protocols only after the backend returns `101 Switching Protocols`. - If the backend instead returned `200 OK`, Pingora could still forward subsequent bytes directly to the backend. - An attacker could pipeline a second, partial request—such as `/admin`—after the initial upgrade request. - This bypassed Pingora’s normal ACL or WAF processing and left Pingora and the backend disagreeing about request boundaries. - A later request from another user could complete the attacker’s partial request, causing the backend to return the attacker’s response to the wrong user. - Pingora 0.8.0 now enables pass-through mode only after receiving a valid `101` response. ## HTTP/1.0, Close-Delimited Bodies, and Transfer-Encoding - Another attack resembled a classic CL.TE desynchronization: - Pingora used `Content-Length` to determine the request body length. - The backend interpreted `Transfer-Encoding: chunked` and ended the body at the zero-length chunk. - The example combined: - HTTP/1.0 - `Connection: keep-alive` - Multiple transfer encodings - Both `Transfer-Encoding` and `Content-Length` - Pingora’s earlier transfer-encoding detection was too simplistic: - It only checked whether `Transfer-Encoding` contained “chunked.” - It assumed a single encoding or header. - HTTP specifications require the final transfer encoding to determine whether chunked framing applies, creating disagreement between Pingora and backend servers such as Node.js. - These differing interpretations of body boundaries enabled attackers to smuggle a second request through the proxy. ## Hardening and Recommendation Pingora 0.8.0 corrects the HTTP/1 framing and upgrade handling issues and adds defensive hardening. Operators running Pingora as an ingress proxy should upgrade as soon as possible and review whether their deployments expose HTTP/1 connections directly to untrusted clients.

Read original(opens in new tab)
gitlabOriginal article

GitLab Bug Bounty Program policy updates (opens in new tab)

GitLab has updated its HackerOne Bug Bounty program policies to improve transparency and streamline the reporting process for security researchers. These changes emphasize a shift toward local testing environments and provide much-needed clarity on the scope of emerging threats like AI prompt injection and denial-of-service attacks. By refining these guidelines, GitLab aims to protect its production infrastructure while ensuring researchers have clear, objective criteria for submitting high-impact vulnerabilities. ### Enhanced Testing Guidance * GitLab now strongly recommends using the GitLab Development Kit (GDK) for local testing, allowing researchers to experiment with cutting-edge features without risking production stability. * Researchers investigating potential Denial-of-Service (DoS) impacts are advised to use self-managed GitLab instances that meet or exceed standard installation requirements. * Any testing performed on GitLab.com production architecture must utilize test accounts created specifically with the `@wearehackerone.com` email alias. ### Refined Vulnerability Scope * Denial-of-Service (DoS) is generally classified as out of scope, though exceptions exist for application-layer vulnerabilities—such as ReDoS or logic bombs—that cause persistent service disruption via unauthenticated endpoints. * Standalone prompt injection is no longer eligible for bounties unless it serves as a primary vector to achieve security breaches beyond the initial AI boundary. * The policy clarifies the distinction between metadata enumeration and privacy breaches, noting that general information gathering remains out of scope while exposure of confidential data is strictly in scope. ### Transition and Grace Period * To support researchers with ongoing investigations, GitLab is honoring a seven-day grace period for DoS reports submitted before January 22, 2026 (9:00 p.m. PT). * Reports submitted during this window will be evaluated under the previous policy to ensure fairness and maintain trust within the researcher community. Security researchers should immediately update their testing workflows by downloading the GitLab Development Kit and reviewing the updated CVSS calculator on the HackerOne program page to ensure their findings align with the new severity standards.