01
Penetration testing
Web, mobile, API, and cloud targets tested the way an adversary would. Findings are written up so your engineers can fix them, not just file them.
Offensive Security
We think like attackers.
Before BlockShift built anything, its founders spent years breaking things, responsibly. Our vulnerability research has been acknowledged by some of the most attacked platforms on the internet. That adversarial mindset is available to clients directly.
Security research acknowledged by
- Spotify
- Booking.com
- Coinbase
- Tinder
- Bumble
- Quora
- Zendesk
- Dynatrace
- Grammarly
- Hyatt
- SEEK
- Razer
- DJI
Verified findings
Resolved on HackerOne and Bugcrowd.
Every vulnerability we reported through bug bounty programs at Medium severity or above, grouped by class. Open a card to see how we hunt for that class and which vendors fixed what we found. Undisclosed reports are described by class, not title, and private programs are not named.
HackerOne
- 32
- valid vulnerabilities credited
- 30
- programs sent thanks
- 2016
- member since
Bugcrowd
- 14
- valid vulnerabilities credited
- 8
- bounties awarded
- 4
- programs in hall of fame
Google Bug Hunters
- 2
- vulnerabilities fixed by Google
- 4
- Google VRP awards
Meta Bug Bounty
- 2018
- Facebook hall of fame
- 1
- resolved report, bounty paid
6 reports up to Critical Broken access control
Reading or changing data that belongs to someone else.
Booking.com · Hyatt Hotels · Inflection
What it is
The server checks that you are logged in but not that the record you asked for is yours. Swap an identifier and you are looking at another customer’s fleet, listing, document, or organization. It is the most common serious bug in multi-tenant products, and the one internal teams most often miss because every individual screen looks fine.
How we find it
- Map every object type the product exposes and every endpoint that creates, reads, updates, or deletes it, including the ones only reachable from the mobile app or a partner portal.
- Replay each request from a second account with a different role and a different tenant, changing one identifier at a time.
- Give delete and fetch paths the same attention as create. Those are the ones teams forget to guard.
- Chase indirect routes: exports, downloads, relationship endpoints, and anything that takes an ID in a body rather than a URL.
Resolved by
- Booking.com Insecure direct object reference in a partner marketplace flow
- Booking.com Insecure direct object reference when updating partner location data
- Private program Access control bypass
- Private program Improper access control in file downloads
- Hyatt Hotels CMS dispatcher filter bypass exposing internal query endpoints
- Inflection Download any company’s uploaded documents
5 reports up to High Authentication and session
Getting in, or staying in, without the credentials that should be required.
Assembla · Google · Inflection
What it is
Login, two-factor, password reset, invitations, and email change each make an assumption about what can be trusted. When one step trusts something another step can change, the whole chain gives way: a reset token that outlives an email change, a second factor that a reused browser skips, a mobile client that never asks for it at all.
How we find it
- Chart every path that ends in a session, including mobile clients and support-driven flows, and write down what each step trusts.
- Change state elsewhere in the flow, then come back: swap the email, forward the invitation, reuse the browser, expire nothing.
- Test the second factor on every client separately. Web and mobile are usually implemented by different teams.
- Look at how support and ticketing systems assign email addresses, since those can become a login identity on the main product.
Resolved by
- Private program Two-factor authentication weakness
- Private program Support-ticket email verification bypass
- Assembla Multi-factor authentication bypass via the mobile application
- Google Authentication bypass in Apigee, Google Cloud’s API platform
- Inflection Password reset token not invalidated on email change
5 reports up to High Injection
Input that comes back as code: in the browser, in a spreadsheet, in a macro.
Inflection
What it is
Anything the product stores and later renders, exports, or embeds is a candidate. Stored cross-site scripting lets one user run script in another user’s session; a formula in a CSV export runs when an administrator opens it in a spreadsheet. Rich-text and macro features are the usual entry point because they render HTML on purpose.
How we find it
- Trace each input to every place it is output, not just the page it was entered on: profile cards, admin views, emails, exports.
- Treat exports as a rendering surface. A CSV opened in Excel is an execution context.
- Probe features that intentionally accept markup (macros, templates, rich profiles) for the boundary between allowed and executable.
- Prefer stored over reflected. It reaches other users, and other users are where the impact is.
Resolved by
- Private program Stored cross-site scripting
- Private program Stored cross-site scripting
- Private program CSV formula injection
- Private program Stored cross-site scripting reaching other users
- Inflection Stored cross-site scripting in company profile
6 reports up to Critical Request forgery
Making the server, or another user’s browser, send a request it should not.
Dynatrace · Superhuman (formerly Grammarly) · Google
What it is
Server-side request forgery turns a URL-fetching feature (a webhook, an integration, a link preview) into a proxy into the vendor’s own network, where cloud metadata endpoints hand out credentials. Cross-site request forgery makes a logged-in user’s browser perform an action, such as deleting their account, from a page the attacker controls.
How we find it
- Find every feature that fetches a URL on the user’s behalf and point it at internal and cloud-metadata addresses.
- Test how the fetcher handles redirects and unusual status codes, not just the first request. Filters are often applied only to the URL you typed.
- For state-changing endpoints, remove the anti-CSRF token and check whether the request still succeeds, with extra attention to flows tied to third-party sign-in.
Worked example: Dynatrace, Critical (10.0)
Dynatrace’s custom integration webhook refused 301 and 302 redirects but followed a 303. A webhook pointed at a page that answered 303 to the AWS metadata service returned the instance’s IAM credentials in the test-notification response. Dynatrace fixed it, paid its maximum bounty, and disclosed the report.
Read the disclosed report ↗Resolved by
- Dynatrace SSRF in the Custom Integration Webhook discloses AWS metadata
- Private program Missing CSRF protection
- Superhuman (formerly Grammarly) CSRF on account deletion for Google-linked accounts
- Private program Cross-site request forgery on an authenticated action
- Private program Cross-site request forgery on an authenticated action
- Google Cross-site request forgery in Google Classroom
3 reports up to High Exposed secrets and services
Credentials in public code, internal tools reachable from the internet.
SEEK · Spotify
What it is
Large engineering organizations leak at the edges: a password committed to an open-source repository, a build-artifact server that answers to anyone. Nothing is exploited in the classic sense. The door is simply open.
How we find it
- Search the organization’s public code and package footprint for committed credentials, including history that has since been rewritten.
- Enumerate subdomains and hosts for internal tooling (artifact stores, CI, dashboards) and check what each returns to an unauthenticated request.
- Verify impact before reporting: what does the credential unlock, what can be read or downloaded.
Resolved by
- Private program Exposed internal service
- SEEK Employee credentials from public breaches still valid on a corporate analytics portal
- Spotify Credential committed to a public open-source repository
4 reports up to Medium Logic and configuration
The product does what it was built to do, and that is the problem.
Haufe Group · Kyivstar · The Iconic
What it is
Race conditions, invitation links that can be forwarded, a login form served over plain HTTP. None of these is a coding error in a single line. They are decisions about ordering, trust, and defaults that only fail when someone pushes on them.
How we find it
- Send concurrent requests to any flow that approves, redeems, or counts something once.
- Forward, reuse, and replay every link the product emails out.
- Check the boring defaults: transport security on every page that takes a password, not just the home page.
Resolved by
- Haufe Group Open redirect on the login page
- Private program Race condition in invitation approval
- Kyivstar Login page served over plain HTTP by default
- The Iconic HTTPS not enforced on login and signup
Private programs are invite-only or were redacted by the customer, and their terms do not allow us to name them. Severity ratings are the program’s own, as recorded on HackerOne (Medium and above) and Bugcrowd (P3 and above). Google VRP does not publish a severity, so those rows show fix status instead.
What we offer
Offensive security services
02
Smart contract audits
Contract review by engineers who deploy to Ethereum, Solana, Polygon, and Arbitrum in production. We audit what we know how to build.
03
Attack-surface review
A structured map of what your product exposes (endpoints, integrations, secrets, assumptions) and which of it an attacker would reach for first.
04
Security advisory
Ongoing access to the founders for threat modeling, architecture review, and incident questions. Security judgment on tap, without a full-time hire.
Need your product attacked before someone else does it?
Tell us what you are shipping and what you are worried about. We will tell you exactly how we would approach it.
Book a callor write to hello@blockshift.com.pk