Read the researcher's report on HackerOne
The report describes a Maintainer leaking a Sentry token by altering the configured URL in error-tracking settings. It attributes the issue to an incomplete earlier fix, but gives no reproduction details.
How it was found
- A Maintainer accessed the Sentry error-tracking settings.
- They changed the configured URL and could expose the Sentry token.
- Access needed
- A privileged role · an account
- User interaction
- None
- Whose object
- No object involved
- Boundary crossed
- A Maintainer exposed a Sentry integration secret through its settings.
- Root cause
- The earlier fix did not fully prevent token disclosure when the configured URL was changed.
- Impact
- A Maintainer could obtain the Sentry token under unspecified circumstances.
- Components
- error-tracking settings
- Confidence
- low
Leaked secret or keyInformation disclosure
This analysis is CyberSIXT's own summary of the public report, written by a model and checked automatically. It may be wrong: the researcher's report is the source. Written 2026-11-15. Ask for a correction or removal.
| Report | Access | Whose object | Boundary crossed |
|---|---|---|---|
| Open prod Jenkins instance | A user account | No object involved | A broadly available Google login granted access to Jenkins administrative capabilities. |
| Employee's GitHub Token Found In Travis CI Build Logs | No account | Another user's | Publicly accessible build logs exposed a token that granted access to private repositories. |
| JSON serialization of any Project model results in all Runner tokens being exposed through Quick Actions | A user account | Another user's | A project commenter obtained Runner tokens from a project they could not access. |
| AWS keys and user cookie leakage via uninitialized memory leak in outdated librsvg version in Basecamp | A user account | The attacker's own | A crafted avatar image exposed memory containing data from the shared server process, including other users’ request data. |
| Google API key leaked to Public | No account | No object involved | Public application responses exposed a credential usable against a third-party billable API. |
| Leaking sensitive information on Github lead full access to all Grab Slack channels | No account | Another user's | A public application release exposed credentials that allowed an unauthenticated outsider to access internal Slack channel metadata. |
| Leaked JFrog Artifactory username and password exposed on GitHub - https://snapchat.jfrog.io | No account | No object involved | Public repository contents enabled access to an internal artifact service and its artifacts. |
| Full access to InDrive jira panel via exposed API token | No account | Another user's | A public repository exposed a credential that enabled access to Jira issues outside the researcher's normal access. |
| Client secret, server tokens for developer applications returned by internal API | A user account | The attacker's own | Sensitive credentials for applications authorized by the account owner were exposed through an internal API response. |
| Netlify Authentication Token Exposed in Public Mozilla CI Logs | No account | Another user's | A public CI log exposed a credential that authorized API access to an organization’s hosting account. |
| Unauthenticated LFI revealing log information | No account | No object involved | Unauthenticated access crossed into local server files and logs. |
| Read files on application server, leads to RCE | A privileged role | No object involved | A project export import read files outside the uploaded archive from the application server. |