Hackerone

3 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)
gitlab3 min readCurated summary

GitLab Patch Release: 19.1.1, 19.0.3, 18.11.6 | GitLab Docs

GitLab released patch versions **19.1.1, 19.0.3, and 18.11.6** on June 24, 2026, addressing important bugs and security vulnerabilities in CE and EE. Self-managed installations should upgrade immediately; GitLab.com is already patched, and GitLab Dedicated customers need no action. The release fixes issues ranging from cross-site scripting and information disclosure to authorization bypasses and improper access controls. ## Release Guidance - The patches apply to GitLab Community Edition and Enterprise Edition. - GitLab recommends upgrading all affected self-managed installations to the latest supported patch release. - GitLab publishes scheduled patch releases twice monthly, with additional critical releases when necessary. - Vulnerability details are generally made public 30 days after the fixing release. - Unless otherwise specified, all deployment types—including Omnibus, source installations, and Helm charts—are affected. ## High-Severity Cross-Site Scripting Vulnerabilities - **CVE-2026-10086 — Analytics Dashboard** - A developer-level authenticated user could execute arbitrary client-side code in another user’s session through insufficient input sanitization. - Affects GitLab EE versions before 18.11.6, 19.0.3, and 19.1.1. - **CVSS: 8.7** - **CVE-2026-10712 — Web IDE Workbench Asset Handler** - Improper path validation could allow an unauthenticated attacker to execute JavaScript in a victim’s browser session. - Affects CE and EE versions before 18.11.6, 19.0.3, and 19.1.1. - **CVSS: 8.0** ## Information Disclosure and Authorization Issues - **CVE-2026-12053 — Duo Workflows** - Insufficient output filtering could expose sensitive information previously committed to a project. - Affects GitLab EE 19.1 versions before 19.1.1. - **CVSS: 7.7** - **CVE-2026-5309 — Virtual Registry Cleanup Policy API** - Authenticated users could read or modify another group’s cleanup policy settings. - Affects EE versions before 18.11.6, 19.0.3, and 19.1.1. - **CVSS: 5.4** - **CVE-2026-2238 — Rapid Diffs** - Unauthenticated users could view confidential issue references on public projects. - Affects CE and EE versions before 18.11.6, 19.0.3, and 19.1.1. - **CVSS: 5.3** - **CVE-2026-11379 — DAST Site Profile Management** - Developer-level users could potentially extract DAST site profile secrets due to incorrect authorization. - Affects EE versions before 18.11.6, 19.0.3, and 19.1.1. - **CVSS: 5.3** ## Additional Security Fixes - **CVE-2026-8330 — CI/CD API** - Sensitive data could be written to application logs because of insufficient filtering. - **CVSS: 4.4** - **CVE-2026-1606 — Snippets** - Authenticated users could conceal content within snippets through improper input validation. - **CVSS: 4.3** - **CVE-2026-5952 — Maven Package Registry** - Developers could bypass package protection rules and overwrite protected Maven package metadata. - **CVSS: 4.3** - **CVE-2026-5796 — Group Packages API** - Reporters could view package metadata from projects where the Package Registry was disabled. - **CVSS: 4.3** ## Recommended Action Administrators of affected self-managed GitLab instances should upgrade to **18.11.6, 19.0.3, or 19.1.1**, depending on their supported release branch, as soon as possible. Updating promptly is particularly important because several vulnerabilities permit code execution, sensitive-data exposure, or unauthorized access.

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.