Report Security Issues
Last Updated: August 2026
Found a weakness in sosiom.com? Tell us. We read every serious report, we fix what turns out to be real, and we pay for the ones that qualify. There is no form to fill in and no portal to register with; one email reaches a person here.
Below: the rules we ask you to work under, our promise not to come after you for following them, what a reward is worth, what falls outside the program, and how to send the report in. Read the scope section before you spend an evening on something we cannot pay for.
Section 01
Our side of the deal
Report a security issue the way this page asks, and we will not pursue legal action against you over it, or push for an enforcement investigation because of it. That protection is the point of having a policy at all. Researchers should not have to weigh a lawsuit against doing the right thing.
Section 02
Your side of the deal
- Give us room to investigate and ship a fix before the issue goes public or gets passed to anyone else.
- Leave other people’s accounts alone. If an account isn’t yours, you need that person’s explicit permission before touching it.
- Take real care not to knock the service over, wipe data, or expose anybody’s private information while you work.
- Stop at proof. Demonstrating the flaw is the goal; pulling data you don’t need to demonstrate it is not.
- Keep the whole exercise inside the law.
Section 03
What a report needs to qualify
Rewards are ours to set, weighed on how severe the issue is, how much damage it could do, and how clearly the report explains it. Beyond that:
- The five points above have to be respected.
- The finding must be a real vulnerability with real risk to a user’s privacy or to the platform.
- It has to arrive through the address at the bottom of this page. Please don’t approach individual staff members.
- Tell us if your testing broke something by accident. Disclosing that helps you, it doesn’t hurt you.
- Every valid submission gets reviewed, though serious issues jump the queue and a complete answer can take a while.
- Once an issue is closed, we may write publicly about what was found.
Section 04
How the amount is decided
Send steps we can follow. A finding nobody can reproduce earns nothing, however interesting it sounds.
Past that, three rules govern the payout: the first person to file a valid report on an issue is the one who gets paid, several bugs traced to one underlying cause count as one report, and the final figure reflects impact, how easily the flaw could be exploited, and how well the report was written.
Section 05
Reward tiers
| Severity | Maximum | Typical findings |
|---|---|---|
| Critical | Up to $200 | Taking over an account entirely without authorization · SQL injection that reaches user data · bypassing authentication vertically · running commands or a remote shell on our systems · remote code execution |
| High | Up to $100 | Session cookies handled insecurely · local file inclusion · stored cross-site scripting · internal data of a sensitive kind left exposed · bypassing authentication laterally |
| Medium | Up to $50 | Insecure direct object references · flaws in business logic |
| Low | Credit, not cash | Disclosure of low-sensitivity information · reflected cross-site scripting · open redirects |
Section 06
What falls outside the program
Some findings are real observations without being vulnerabilities we can act on, and they earn credit rather than cash:
- Scanner output submitted raw, with nothing showing the issue is exploitable here.
- Missing hardening headers where no attack path follows from their absence.
- Weaknesses in software we do not run or control, including our hosting provider’s own infrastructure.
- Social engineering aimed at our staff, and anything requiring physical access to the building.
- Volumetric attacks. Knocking the site over proves only that traffic is traffic.
If you are unsure which side of that line a finding sits on, send it anyway with your reasoning. A short question costs you far less than a wasted week.
Section 07
Sending it in
Email Contact@sosiom.com with a clear description of the flaw, the steps needed to reproduce it, and whatever supports it: screenshots, a proof of concept, request logs. Somebody on our team will read it and come back to you directly.