By participating in this program, you agree to:

• Respect the Community Code of Conduct
• Respect the Intigriti Terms and Conditions
• Respect the scope of the program
• Not discuss or disclose vulnerability information without prior written consent (including PoC's on YouTube and Vimeo)

Introduction

In-scope vulnerabilities will be prioritized and remediated based on severity. This VDP accepts reports containing original and validated vulnerabilities that a potential attacker could use to compromise the confidentiality, integrity, or availability of the services in scope. By participating in this program you agree to follow all of the requirements below. We look forward to working with you to find security vulnerabilities and keep our business and our customers safe, and we will try to keep you informed of our progress throughout the process.

This program follows a "see something, say something" model. Participation does not guarantee a monetary reward; we offer coordinated remediation, public recognition, and our sincere thanks.

Our worst-case scenarios are:

Container Escape from Worker to Host An attacker running code within a Spacelift worker container breaks out of the container isolation boundary and gains access to the underlying host. This could expose other tenants' workloads running on the same host, allow privilege escalation to root, and provide access to cloud instance metadata, including IAM credentials attached to the host machine.

Confused Deputy Attack via Cloud Provider Integration An attacker abuses Spacelift's trusted cross-account access to assume cloud roles they are not authorized to access, effectively gaining administrator-level access to cloud infrastructure across AWS, GCP, or Azure without ever compromising the cloud provider directly.

Any useful infrastructure information:

Spacelift workers execute jobs inside containers where arbitrary code execution is by design. Users control what runs in their stack. Getting a reverse shell into a worker container is expected behavior, not a vulnerability.

A researcher confirmed this: they established a reverse shell, ran linpeas, and attempted privilege escalation exploits but achieved nothing beyond the container boundary. No host compromise, no cross-tenant impact, no data exfiltration.

To be a valid finding, you must demonstrate one of:

• Container escape to the host OS
• Privilege escalation beyond the container
• Cross-tenant impact on other customers' workloads
• Data exfiltration outside the job's expected scope

Reverse shell access alone will not be accepted.

Application

• Session keeps using old user group permissions if user group permissions are changed during a given session's lifespan
• Bypasses of user or API key creation limits (including via race conditions or business logic issues)
• Visibility of users, roles, and resources
  Information visible to authenticated users within the same account in the Spacelift UI or API, such as account members, their roles, or existing resources
• Contact form (especially HubSpot ones)
• Data breaches or credential dumps - third-party claims or notifications about alleged leaked or stolen Spacelift data (for example, posts on the internet claiming possession of Spacelift data or offering it for sale)
• Wordpress usernames disclosure
• Pre-Auth Account takeover/OAuth squatting
• Self-XSS that can't be used to exploit other users
• Verbose messages/files/directory listings without disclosing any sensitive information
• CORS misconfiguration on non-sensitive endpoints
• Missing cookie flags
• Missing security headers
• Cross-site Request Forgery with no or low impact
• Presence of autocomplete attribute on web forms
• Reverse tabnabbing, tabnabbing
• Bypassing rate-limits or the non-existence of rate-limits.
• Best practices violations (password complexity, expiration, re-use, etc.)
• Clickjacking without proven impact/unrealistic user interaction
• CSV Injection
• Sessions not being invalidated (logout, enabling 2FA, etc.)
• Tokens leaked to third parties
• Anything related to email spoofing, SPF, DMARC or DKIM
• Content injection without being able to modify the HTML
• Username/email enumeration
• Email bombing
• HTTP Request smuggling without any proven impact
• Homograph attacks
• XMLRPC enabled
• Banner grabbing/Version disclosure
• Not stripping metadata of files
• Same-site scripting
• Subdomain takeover without taking over the subdomain
• Arbitrary file upload without proof of the existence of the uploaded file
• Blind SSRF without proven business impact (pingbacks aren't sufficient)
• Disclosed/misconfigured Google Maps API keys
• Host header injection without proven business impact
• SSL/TLS issues (e.g. expired certificates, weak ciphers, best practices)
• GraphQL Introspection is enabled

General

• In case that a reported vulnerability was already known to the company from their own tests, it will be flagged as a duplicate
• Theoretical security issues with no realistic exploit scenario(s) or attack surfaces, or issues that would require complex end user interactions to be exploited
• Spam, social engineering and physical intrusion
• DoS/DDoS attacks or brute force attacks
• Vulnerabilities that only work on software that no longer receive security updates
• Attacks requiring physical access to a victim's computer/device, man in the middle or compromised user accounts
• Recently discovered zero-day vulnerabilities found in in-scope assets within 14 days after the public release of a patch or mitigation may be reported, but are usually not eligible for a bounty
• Stolen secrets, credentials or information gathered from a third-party asset that we have no control over
• Exposed secrets, credentials or information on an asset under our control that are not applicable to the program’s scope
• Reports that state that software is out of date/vulnerable without a proof-of-concept

This program follows Intigriti's triage standards based on the proof of concept.

Where can we get credentials for the app?

You can self-register from https://spacelift.dev/free-trial. Please use your GitHub, Google, Gitlab, or Microsoft account associated with @intigriti.me address.

We also ask you to include the email as an email-alias in the X-BugBounty-email-alias header.